Object Oriented Programming Interfaces for Accelerator Control

Several years ago, the AGS controls group was given the task of developing software for the RHIC accelerator. Like the AGS, the RHIC control system needs to control and monitor equipment distributed around a relatively large geographic area. A local area network connects this equipment to a collection of UNIX workstations in a central control room. Similar software had been developed for the AGS about a decade earlier, but isn't well suited for RHIC use for a number of reasons. The AGS software was designed to work within AGS parameters. The AGS software expects data updates at AGS operating rates. This rate is typically every 3 or 4 seconds. The AGS software does not allow large ( greater than about 40 Kbytes ) data transfers. The AGS software enforces a very rigid format for grouping related data. In addition, the AGS software was written for a proprietary hardware platform. An aggressive porting effort was well underway to make the software usable on typical UNIX workstations. However, it seemed that this effort would not be complete in time. More importantly, all software for AGS operations had been written by the controls group. A different paradigm was expected for RHIC software development. The RHIC Accelerator Physics group is composed of experienced programmers. Not only are these physicists fully capable of writing physics applications, they expect to do so. The controls group is expected to provide training and assistance in using control system software. This necessitates a succinct, well-defined application programming interface (API). The AGS software represents accelerator equipment as collections of control points. These collections of control points are called “logical devices”. Other control systems focus more on individual control points, rather then on related groups of control points. The AGS approach contains the rudiments of an object oriented system. It is not truly object oriented, since the “logical devices” do not contain the methods for translating the control points into commands to accelerator equipment. Rather than adapt the AGS software for RHIC use, the controls group opted to start with a clean slate. To develop software that would address the shortcomings of the AGS software, while preserving the useful features that evolved through years of use.